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Abstract: Agile development methodologies are helping software companies and development teams to align to the new 
evolving economy, Agile gainsay and hampers our notion of software engineering practices and project management 
techniques and methodology, and the way we lead our project teams. The Agile movement impacts each role on a project 
team in a different way and creates a lot of chances to learn new skills and develop new ways of working and gaining 
success together. Ague introduces a major shift in the way teams look at software requirements gathering and when they are 
defined in the process. Agile Business Analysts are an unified part of the team throughout the life of the software project 
development cycle and alleviate collaboration across a broader cross section of the project team and the business. 
Collaboration, management, facilitation, leadership, coaching and team building become significant new skills required for 
BA on Agile projects. Leadership and management are key components critical to their success. 
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I. Introduction 

Moving from old project work to agile project work will impact all functional role on a project team separately: 

For Business Analysts (BA), successfully managing an agile project depends on defining requirements in smaller 
increments and working more collaboratively with the team through the life of the project. 

For Project Managers, success moving to Agile development methodologies depends on acquiring the skills necessary to 
progressively plan a project through its lifecycle rather than at the onset. Project Managers will also need to acquire new 
ways of intellect project control and risk. 

For Quality Testers, evolving to an agile framework will mean developing the skills necessary to write tests and validate 
code in parallel with development. 

This paper will explore the impact agile development methodologies are having on the BA community, what new 
skills are required, and what BAs can do to ease the changeover. 

II. Conventional Requirment 

The BA's are learned to believe that they can and should define detailed requirements at the starting of a project. 
Built in this philosophy there are several challenging assumptions. Conventional requirements analysis assumes that: 

Customer can definitively know, enounce, and functionally define what the system or software should do at the end of 
the project 

Once documented, the requirements will not change - at least not without potential project delays, budget overruns, or 
scrawny feature sets 

Requirements process is captive to a single product owner who sits apart from the development team picturing the 
product 

Does not acknowledge the inherited uncertainty in software development that agile methodologies seek to embrace 

Experience shows us that these assumptions are wrong. As we learn more about the evolving system, our 
knowledge will impact the system we want to build. The process of creating the system helps the team learn more about 
what is possible. The act of creating the requirements will cause them to change. Agile methodologies boost us to embrace 
this kind of work to adopt in our projects. We start realizing that change really is nice, it helps us to deliver greater value to 
our customers and attempting to define everything up front results in continuous change management. To fully 
understanding the impact that Agile has on the BA role, it is helpful and required to understand how agile projects are 
running. 

III. Agile Project Management 

According to Agile Project Management the processes need to create good software in today's world are not 
predictable. Requirements with technologies change and as individual team member productivity is highly varying. When 
processes are not fixed and results cannot be predicted, we cannot use planning methods that based on only predictability. 
Instead of it, we need to adjust and change the processes and guide them to give our required outcomes. Agile project 
management does this by maintaining and keeping progress highly visible, inspecting project outcomes regularly, and 
maintaining an ability to adapt to changing circumstances as required. 

Benefits of Agile Project Management are produced in incremental part by having an enormous amount of 
accountability and responsibility on team members. Great teams build great software and those should be trusted and 
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appointed and charge to deliver. The Agile Project Manager helps the team to always stay focused on the several business 
issues and help them to correct and removes obstacles that hinders the team's ability to deliver final product. The focus is on 
the team because they are who ultimately going to deliver. 

As agile teams are self-organizing, agile project manager focuses much on leadership as compared to a conventional 
development environment. Several skills like coaching, facilitation and team building are important components for project 
success. The project manager is creating a trust and an environment where each individual are motivated to contribute to the 
team's success for project. Project Managers focus little on assigning tasks and managing plan and much on maintaining the 
solid structure and discipline of the agile team. By trusting that through visibility, regular inspection, and proper adaptation 
the team will deliver the noticeable and desired results. This philosophy change the role of the BA for how requirements are 
gathered, distilled, and managed [1]. 

IV. Collaborative Requirments 

1. Introduction 

As opposed to conventional requirements gathering, where the BA major works with the client is only to gather 
requirements, here agile team members are involved in gathering and defining all product requirements. Domain specific 
technical team members and testing team or QA team collaborate with the product owner and the BA to develop and 
maintain the project specifications by bringing their all technical skills and experience into this collaborative and collective 
process. Increasing interaction enables and ensures team to develop requirement document and specifications that can be 
created and tested under the all project constraints. 

To deal with scope on an agile project, specifications and requirements must be considered in two dimensions 
which are breadth first and then depth. It is necessary to understand the breadth of what we want to build early in the project 
cycle. Working with breadth of the solution helps team to understand scope and cost that will facilitate them estimating, 
release and planning. The breadth of a project starts to frame the boundaries of the product and helps to manage and cope the 
organization's expectations. Breadth of the requirements is a much little investment of time and resources as compared with 
dealing with the entire depth. The details are likely to evolve when we progress through the project so defining it early has 
little value. To have a good understanding of the breadth of project requirements early in the project lifecycle helps 
development team start to define the set of all possible solutions. The BA plays a major role in alleviate the conversation 
between the product owner, managers, the technical team with QA team. BA ensures that the full scope of requirements has 
been defined and balanced by technical and domain understanding of the solution. 

Once the team has created the breadth of the solution, then they begin incrementally looking at depth of it. The BA 
take the lead in helping the team by bring requirements to this next level of detail. For this we have to abandon our 
conventional notions of the Marketing, Product Requirements Document and the list of the system specifications. Instead, 
we have to focus only on how the system will behave in future. 

To manage requirements effectively in a conventional and traditional environment, Business Analysts sort through 
many-to-many (M-to-M) relationships [2] between business design, and specifications elements. Because of complex 
interactions among these M-to-M relationships, requirements management industry had created tools to trace their 
interdependence among them. BA will track the impact of any requirement change to its corresponding design element or 
from a change in design element back to requirement. This process can get even more complex when one traces into the 
software component and test results. 

1.1. Agile Requirements 

Based on the level of process required by an company, BAs will use either use cases or user stories. Agile methods 
basically tend to be light weight specifications and requirements are documented as user stories. User story is a high level 
description of system behavior and it is not a full specification of the requirement but a placeholder for conversation about 
the requirement of system. The user story will be fully documented and specified as it is brought into a development cycle. 
After delivered, a user story represents a fully functional slice of the overall system. Here are the suggested guidelines to 
determine what makes a good user story. Bill Wake defined the INVEST model for definition of requirements [3]: 

Independent 

Avoid dependencies among stories 
Write to establish foundation 

• Combine them if possible in a single iteration 

Valuable 

Each story should show some value to the Users and Stakeholders 
Estimable 

Enough detail should be provided to allow the team to estimate 

• Team will only encounter problems estimating if the story is very big, or if insufficient information is given, or if there 
is lack of domain knowledge about it 
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Sized Appropriately 

Every story should be small enough so it should be completed in a single iteration 

Stories that needed to be worked on in near future should be smaller with more detailed and big stories are acceptable if 
planned further out 

Testable 

Acceptance criteria should be written in customer terms 
Tests should be automated if possible 

Every team members should demand a clear acceptance criterion for it. 

V. New Analysis Skills For Ba 

Agile BA will basically depend on facilitation skills of people instead of on conventional projects. BA's role is to 
conduct a discussion between product owner and software development team. BA will bring a tremendous amount of system 
and domain knowledge to the discussion and is positioned to get functional requirements from product owner. BAs help to 
translate user requirements into more technical language for the development team. Apart from coaching, facilitation and 
team building, agile BA needs to think about the software development process in new and non conventional ways. Agile 
helps us to decouple breadth of the solution from the depth of the solution to deliver smaller increments of production-ready 
code. This can cause a difficulty for some analysts making the transition to Agile from traditional way and will create 
opportunities to learn about how to write feature (functional) driven requirements [4]. BA can be asked to work on an agile 
project as the project has a high need for written functional specifications and design documents. In both case, BA primary 
role is to conduct understanding and communication. 

While it is ideal is to have a product owner or an on-site customer, for many teams this is not possible. For those 
teams, the BA may have to fill the role of a customer proxy. Having the role of the customer proxy puts a significant amount 
of additional responsibility on the role of the BA. In this scenario, the BA is asked to understand the needs of the customer 
and translate those needs to the development team. This model introduces risk because the true end customer is not directly 
involved with the people developing the product. The BA can mitigate this risk by encouraging the product owner to review 
the evolving system as frequently as possible. 

VI. Agile On Conventional Project 

Moving to agile is not usually the decision of the Business Analyst. However, given the BA's critical role on the 
project, there is often quite a bit they can do to help set the stage for an agile transition. The BA can encourage collaboration 
between the product owners and the technical teams. This will ensure that requirements are balanced and feasible[5]. This 
will tend toward managing expectations and helping the project owner to understand the cost of the solution they are 
spending. The BA can begin to demonstrate the value of loosely coupled functional specifications and begin introducing use 
cases or user stories to the team members. When the specifications are completed, the development team will derive value 
from a functionally-driven specification. System will be easy to develop and test and traceability will be a non-issue. If 
software team has dedicated QA members, agile requirements will enable functional testing process. Test plans should be 
derived from functional organized specifications. 

VII. Conclusion 

Success in present economy needs us to react quickly to always changing software market conditions. Traditional 
and conventional products delivery methodologies alone cannot deliver quick enough in such highly uncertain project 
domains. Software agile processes allow BA and development teams to meet changing demands of their customers while 
developing nice environments where all team members want to work. 

BA can play a major role on an agile team success, by shift their traditional and conventional thinking about 
requirements. Secondly, Business Analyst's need to consider learning new skills for understanding and writing requirement 
documents and new techniques for managing them. Success for result will depend mainly on how well BAs learn and adapt 
to these new ways of working with all kinds of requirements, using group collaboration and setting up functional and 
technical teams. 
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